SourceGear Vault Configuration Examples

Minimal example:

<sourcecontrol type="vault" />

Full example:

<sourcecontrol type="vault" autoGetSource="true" applyLabel="true">
           <executable>c:\program files\sourcegear\vault client\vault.exe</executable>
           <username>my_username</username>
            <password>my_password</password>
            <host>my_buildserver</host>
            <repository>my_repository</repository>
            <folder>$</folder>
	    <ssl>true</ssl>
	    <timeout units="minutes">10</timeout>
	    <useWorkingDirectory>true</useWorkingDirectory>
	    <workingDirectory>project/src</workingDirectory>
</sourcecontrol>

Configuration Elements:

*: it is possible to deposit these values with the Vault command-line client so that they do not need to be stored in the ccnet.config file. Type vault help rememberlogin at a command prompt (where vault.exe is accessible) for information.

Plugin available for Vault 4.1+ (or Fortress 1.1+)

SourceGear has released a plugin that offers better performance and accuracy by interacting directly with Vault via its API, rather than the command line. The configuration format is almost identical to this one, making migration easy. The plugin and its documentation can be downloaded from SourceGear's site.

Vault Working Folder Defined

Most version control systems have distinct commands for "get me the source" and "get me the source into a folder where I may make changes." Vault is no exception. A working folder is a folder where Vault will keep track of your changes. If you're using CC.NET 1.1.0.2172+, the useWorkingFolder setting determines whether Vault retrieves source into a working folder. For build purposes, there are typically two situations where you want to retrieve source into a working folder:

1. Your build script changes source and checks in the change
2. It's taking longer than you'd like to retrieve the source

Because of the additional state information kept by Vault for working folders, retrieving source into a working folder is usually faster than into a non-working folder. The trade-off is that more disk space will be used for cache and state data.

Filtering out Label Changes

If you are using Vault 3.x or later, labels will automatically be filtered. However, if you are using an earlier version of Vault and you apply a label as part of your build process, this will kick off another build. you will need to use a Filtered Source Control Block to get around this. If your build server uses a specific user id to integrate with Vault, you can set up a UserFilter to filter out all changes made by that user.

Problems with CCService and Vault 3.0.2+

If you are experiencing problems detecting modifications using CCService after upgrading to Vault 3.0.2, it may be related to the enhanced security features of the Vault server. You should try the following process to fix this issue:

• reinstall the Vault Server to have the IIS Process Model run as System (ie. not Machine)
• change the CCService to run as an actual user, not as LocalSystem.

Problems with releases prior to Vault 3.0

For versions of Vault prior to 3.0, the -excludeactions argument is not supported. To get around this problem you should explicitly specify the <historyArgs> element in your ccnet.config file so that it does not contain that argument (ie. set it to <historyArgs>-rowlimit 0</historyArgs>.

NAnt Vault Tasks

SourceGear has produced some NAnt tasks for Vault that can be downloaded from here.

Turning off the creation of _sgbak folders

Using CC.NET 1.1.0.2172+ and Vault 3.1.7+, _sgbak folders are never created.

Using older versions, the use of the _sgbak folder can be turned off using the GUI client. This is a user and machine-specific setting, so you need to launch the GUI client on the CCNet machine and log in as the same Vault user that CCNet is using (as specified it ccnet.config).

Tools|Options -> Local Files -> Cache/Backup Locations -> Un-check "Save files in backup folder before overwriting"

Code contributed by Ryan Duffield, Leo von Wyss and Ian Olsen.